1. Field of the Invention
The invention is in the field of computer system management and more specifically, the management of virtualized and cloud-based computer system resources.
2. Related Art
Virtualized computing using machine hypervisors such as VMware's vSphere, VMware Workstation, Microsoft's Hyper-V and the open source hypervisors, Xen and KVM, have become a popular way to provide computing resources not only inside the computer data center but also form a key component of cloud-based computer resources. Using machine hypervisors allows many virtualized computer operating system environments (“guests” or virtual machines) to be executed in isolation from each other on a single physical hardware computer system.
As the number of virtualized environments and machine hypervisors increased, new computer system management tools were required in order to maintain the increasingly complex datacenter. The tools are typically supplied by the hypervisor vendor and normally implemented as separate management clients and servers. The client-server communication protocol is typically a mix of public and private APIs that are proprietary to the platform vendor. In this case proprietary is used to mean that an industry or other standards body does not control the APIs, rather than closed vs. open source. Those management tools that support multiple hypervisors do so by replacing the management client and accessing each hypervisor's functionality using its public management API.
FIG. 1 illustrates a typical management infrastructure for virtualized environments of the prior art.
Management Client 100 communicates to a management service 120 executing on the computer 101 comprising CPU 102, memory 103, network I/O 104 and storage 105, using the platform's native public APIs 110 or native private APIs 111. The management service 120 communicates to remote hypervisors 131, 151, 171 each running on their own computer system 130, 150, 170 respectively. Each computing system 130, 150, 170 comprises a CPU 141, memory 143, storage 144 and network I/O 145. The protocol used for communication between the management service 120 and the hypervisors 131, 151, 171 is platform specific. Management Client 100 may directly communicate with hypervisors 131, 151, 171 for high performance, low latency data streams such as a virtual machine's remote console. Hypervisor 131 may itself expose a set of public APIs 132 or private APIs 133 for use by the management server 120 or the Management Client 100. The APIs 132, 133 expose virtualized views of the physical resources of the hypervisor such as CPU 141, memory 143, storage 144 and networking interfaces 145. The APIs may also expose logical resources such as virtual machines 134, virtual networking 135 and configuration data for the various software components that make up the hypervisor platform. Hypervisors 131, 151, 171 may communicate with the management server 120 directly, rather than waiting for the management server to poll them for new data.
FIG. 2 illustrates the typical components of Management Service 120 as found in the prior art.
Management Service 120 typically comprises a datastore 210, authentication service 220, web-based management console 230. The datastore 210 stores both permanent configuration information and time-based performance metrics for aggregating and reporting. The data in datastore 210 may be stored as records in a SQL database, a flat file or other storage layout. The datastore maybe co-located with the management service 120, or as part of a remote datastore 260 executing on computing system 250, itself comprising CPU 251, memory 252, network I/O 253 and storage 254. The authentication service 220, may use remote authentication services 240
Each hypervisor vendor has adopted its own architecture for implementing its public APIs. Each follows a different and non-compatible route. For example VMware utilizes a SOAP based API, Microsoft uses WMI, Xen uses XML-RPC, Red Hat KVM a client-server API, while the Amazon cloud service currently supports both a SOAP and non-XML REST-based interface. Even with the technology, each has unique API implementation details that make supporting multiple hypervisor platforms a complex and incomplete task, including the use of private or undocumented APIs.